Java Card is a well known technology which provides a secure environment for software Java based applications also called “applets” to be run on a secure element. Such secure elements, compliant with Java Card Standard, may sometimes face software bugs when they are already issued and on the field.
The bugs may be located in the Java Code or in the native code. When in the java code, the bugs may be fixed by loading a java patch on the secure element. This solution is already known and accepted by certification authorities. A secured load post-issuance for embedded code and Java Card content and linking is described in standards such as GlobalPlatform and JavaCard for example in Cap File format on Java Card, Loading command on GP.
When in the native code, a solution may consist in implementing a specific proprietary loader inside the secure element, with its dedicated security verifications.
However such solution would require to be reviewed by security labs on the deployment method and on the code content in order to avoid attacks on the native code fix, either when the fix code is loaded by a non authorized party, or when a malicious code is injected inside load blocks during the loading process by an authorized party. Moreover the implementation of a specific proprietary loader itself may be costly in term of memory space in the secure element, and could provide some security holes.
It is then an object of the invention to provide a method for securely loading a native code on secure element post issuance, for correcting one or several bugs of the native code once the secure element is issued on the field.
Thereto, the present invention provides a method for loading at least one native code on at least one target secure element, said method comprising the following steps:                providing a modified CAP file composed of at least one custom CAP component comprising a native code;        extracting said native code from the custom CAP component;        installing said native code in the target secure element.        
Thanks to the method, bugs located in the native code may be corrected easily in post-issuance.
According to another aspect of the invention, the method may comprise embedding a platform's signature as a dedicated Java Card custom CAP component into said at least CAP file or into the at least one custom CAP component.
According to another aspect of the invention, the at least one custom CAP component may comprise a custom header component parameter, a header and the native code.
According to another aspect of the invention, the custom CAP component header may comprise information on the size, the type and number of corrections or of new elements or of functions to be added.
According to another aspect of the invention, the header information may comprise information on the section or sub-section where the correction(s) or added function(s) have to be done, and the size of said compiled corrections or added elements or functions.
According to another aspect of the invention, the method may comprise determining whether the at least one custom CAP component is sent by an authorised party by comparing a platform's component embedded in the custom CAP component with a signature embedded in the target secure element, the party being considered as authorized if the two signatures are identical.
According to another aspect of the invention, the method may comprise aborting the loading process if the Operating System of the target secure element determines the at least modified CAP file comprising the custom CAP component is not sent by an authorized party.
According to another aspect of the invention, the method comprises grouping a set of native codes as one or more custom CAP components into one single or several modified CAP files in order to load said set of native codes into a set of secure elements, each native code embedding a platform's signature.
According to another aspect of the invention, the step of compatibility signature may comprise comparing the platform's signature embedded the one or more custom CAP components and the platform's signature of each secure element of said set of secure elements.
According to another aspect of the invention, the method may comprise deploying the one or several modified CAP file post issuance remotely.
According to another aspect of the invention, the method may use an IJC file instead of a CAP file.
The present invention also provides a method for generating a modified CAP file comprising at least a native code to be loaded on at least a target secure element comprising a Java Card Virtual Machine, said method comprising the following steps: generating a native code to be executed by the target secure element; generating a first CAP file comprising a set of CAP components; generating a modified CAP file by adding to the first CAP file a custom CAP component comprising the generated native code.
Thanks to the invention, the loading deployment method of the new native code is secure. The native code fix is integrated using custom Java card component. It facilitates the deployment on server side for example on a Trusted Server Manager, using the current loading method in term of content and security.
The secure element verifies the compatibility signature from the native component with its own build signature.